fix(adapters): route azure-foundry through apiBase without /openai/deployments/{deployment} (#13114) - #13161

Description

AzureApi._getAzureBaseURL previously forced every provider: azure request through the legacy Azure OpenAI Service URL shape (/openai/deployments/{deployment}?api-version=...) regardless of env.apiType. That 404s on Azure AI Foundry (a.k.a. Microsoft Foundry) endpoints, which expose an OpenAI-compatible /openai/v1 path supplied by the user in apiBase.

The AzureConfigSchema in packages/openai-adapters/src/types.ts already declares apiType: "azure-foundry" as a valid value, but the AzureApi implementation never branched for it. This PR adds the branch:

• When env.apiType === "azure-foundry", return the apiBase (with trailing slash trimmed, search params extracted into defaultQuery) without appending /openai/deployments/{deployment}.
• Skip the env.deployment / env.apiVersion requirements for foundry (those are Azure OpenAI Service-only).
• azure-openai / azure paths keep their existing behavior.

Reproduction (from the issue)

name: Main Config
version: 1.0.0
schema: v1
models:
  - name: gpt-5.3-codex
    provider: azure
    model: gpt-5.3-codex
    apiKey: YOUR_API_KEY
    apiBase: https://<your-resource>.services.ai.azure.com/openai/v1

Before: AzureApi rewrites apiBase to https://<your-resource>.services.ai.azure.com/openai/v1/openai/deployments/<deployment> and the Foundry endpoint returns 404.
After: apiBase is used as-is; the request reaches the Foundry OpenAI-compatible routing path.

Tests

Added 2 regression tests in packages/openai-adapters/src/test/main.test.ts:

• should configure Azure AI Foundry client without appending /openai/deployments/{deployment} — verifies the baseURL is the user-supplied apiBase.
• should not require env.deployment or env.apiVersion for Azure AI Foundry — verifies no deployment / apiVersion is required for apiType: "azure-foundry".

The fix was verified by extracting _getAzureBaseURL into a standalone Node script and running 6 cases (3 legacy azure-openai + 3 foundry) against hand-computed expected baseURLs (all pass). I could not run the vitest suite in this environment (no node_modules at the workspace root); the upstream vitest suite should be re-run by the maintainer.

Checklist

• I've read the contributing guide
• The relevant tests have been updated

I have read the CLA Document and I hereby sign the CLA

🤖 Generated with Hermes Agent